System and method for pooled electronic purchasing

ABSTRACT

A retailing method executable by a computer system, includes sending a page to a prospective purchaser in response to a request, the page being associated with a specific product; receiving a purchase proposal from the prospective purchaser for direct purchase of the product at a fixed price, the purchase proposal including identifier information of persons nominated by the prospective and purchase term information selected at least in part by the prospective purchaser, the nominated persons being nominated to contribute to purchase of the product at the fixed price.

This application is the US national phase of international applicationPCT/AU02/00623 filed 20 May 2002, which designated the US.PCT/AU02/00623 claims priority to AU Application No. PR 5133, filed 21May 2001. The entire contents of these applications are incorporatedherein by reference.

A. FIELD OF THE INVENTION

The field of the invention is automated joint purchasing. In particularit is a computer implemented system and method for accumulatingdonations towards a specific gift (as opposed to a gift voucher) usingan electronic communications network such as the Internet. This iscalled Pooled Electronic Purchasing or PEP.

B. BACKGROUND TO THE INVENTION

There are many occasions when people purchase gifts jointly rather thanseparately. Such purchases are often made for birthdays, weddings andengagements, mothers' and fathers' days, retirements, leavings andgoings away, bar mitzvahs and bat mitzvahs etc.

The motivations for making such purchases are numerous. For example, byjoining their individual donations, the participants can afford a moreexpensive gift than they would be able to afford separately. There arealso times when individuals regard the act of contributing to a jointgift as being appropriate or desirable in itself. For example, all ofthe children in a family might want to give their parents a jointanniversary gift, or all of the members of a sporting team might want togive a departing member a gift from the entire team. The co-operationexhibited can signify the connection between the gift givers and theirrelationship with the recipient. Another motivation held by peopleparticipating in a joint gift is convenience. It is often moreconvenient for a group of six people to organise one gift between themrather than six gifts separately. Often, people giving joint gifts willhave more than one motive behind their actions.

3. Traditional Joint Purchasing

Traditionally, group gifts are bought when group members physicallytravel to a store where they choose, pay for, and pick up the item.

However, people frequently encounter problems when buying joint gifts inthis manner. Depending upon the particular circumstances:

-   -   it may be difficult or impossible to get people together to        coordinate the purchase (due to them living or working far apart        or leading busy lives);    -   not everyone has a say in selecting the goods or services;    -   a minority of the group has the burden of choosing and        collecting the gift;    -   the person who pays the supplier may encounter difficulties in        being reimbursed, perhaps recovering payment late (possibly        incurring interest charges) or not at all;    -   some people ultimately pay too much or too little; and    -   the person who pays the supplier obtains all of the rewards        program points associated with the payment, while the others        receive none.

When group gifts are organised using traditional methods, vendors missout on valuable information that can assist their businesses. In mostinstances, there is no way for the retailer to know that the purchase isa gift, or to identify the recipient or the other people involved in thepurchase of the gift. There is no way for the retailer to turn theseabsent parties into customers.

1. Electronic commerce prior art

The relevant prior art can be divided into three groups: demandaggregation systems, person-to-person (P2P) payment systems and donationaccumulation systems.

a) Demand aggregation systems

An example of a demand aggregation system is described in PatentPublication Number WO00/45318, “Aggregating on-line purchase requests”.This system aggregates demand for particular products so that multiple“low volume” purchasers can take advantage of high volume discounts. Itoperates in accordance with a “buy cycle”, which is constituted by:

-   -   a server posting a web page containing an offer describing a        product and listing prices for various quantities of that        product;    -   the acceptance and aggregation of multiple purchase orders from        a plurality of purchasers; and    -   the closing of the offer in accordance with pre-established        criteria, generally with the aim of maximising the quantity sold        and minimising the unit price.

This system is designed to lower the unit price that can be obtained bythe purchasers, and to increase the vendor's ability to attract largevolume orders. This is a common feature of all demand aggregationsystems. However, such systems are of little or no relevance toindividuals wishing to purchase a joint gift. First, they do notfacilitate the purchase of a single item or a small volume of items by agroup of purchasers, as they are concerned with the aggregation ofmultiple purchase orders rather than the accumulation of thecontributions from a plurality of purchasers to create a single,indivisible purchase order. Secondly, the minimization of the unit priceis rarely the primary motive for buying a group gift. It can be seenthat the present invention does not operate in accordance with a “buycycle” as defined in Patent Publication No. WO 00/45318, or inaccordance with other demand aggregation systems.

b) P2P Payment Systems

The prior art also discloses a number of systems—known asPerson-To-Person or P2P Payment Systems—that utilise the Internet toenable payments between individuals. One such system can be found atwww.paypal.com. In order to make a payment using this system, a person(the donor) becomes a member by setting up a Paypal account. Thisaccount is linked to a private bank or credit card account. The donorsends an email to his or her friend (the recipient), stating that thesum can be collected from the Paypal site. When the recipient visitsthis web site, he or she becomes a member (if not already a member), andcan then accepts the transfer of the money. The Paypal systemadministers the transfer of the funds between the linked bank or creditcard accounts of the donor and the recipient. Similar systems may befound at www.c2it.com, and paydirect.com.

Such systems can be used to organize group gifts. One group member canpurchase the item, and can then ask the other members to pay for theirrespective shares by using one or more P2P payment systems. This meansit is not necessary for the gift givers to get together in order toexchange their payments. Further, by using Internet services such as theWorld Wide Web and e-mail, the gift givers can each have a say in thechoice of the gift, and it can be delivered to one of the group ordirectly to the recipient. Lastly, it is possible for more than one ofthe joint purchasers to obtain the rewards points associated with theuse of credit card or other electronic payment systems.

Nevertheless, when used to coordinate the payments for group gifts,these services invariably involve a number of disadvantages for thejoint purchasers. For example:

-   -   as with traditional methods, the person who pays the supplier        may encounter difficulties in being reimbursed by the others;    -   it is still possible that some people will pay the wrong amount;    -   the joint purchasers are usually required to become members of        the various P2P Payment Systems before they can make or receive        payments (which may involve cost and inconvenience);    -   the systems require the completion of at least two distinct        stages: the purchase of the gift from the vendor, and the        payments between the joint purchasers; and    -   the systems usually require one of the joint purchasers to keep        track of the payments between the group members.

The use of P2P Payment systems by customers does not solve any of thedisadvantages for the retailers, who still have no systematic way ofknowing that the purchase is a gift, or the identity of the peopleinvolved in the purchase of the gift. Again, there is no way for theretailer to turn these absent parties into customers.

c) Donation Accumulation Systems

The last group of prior art systems can be referred to as donationaccumulation systems. These systems use computers to register andaccumulate the offers of joint purchasers, and to effect a purchase.Unlike demand aggregation systems, donation accumulation systemsfunction in low-volume as opposed to high volume purchasingenvironments.

The first such system is one described in U.S. Pat. No. 5,794,219,entitled “Method of conducting an on-line auction with bid, pooling”.This patent describes a method of accumulating bids from multiplemembers of an auction consortium during a bidding session at an on-lineauction. A central computer coordinates the registration of biddinggroups, and then combines the bids from the individuals in theconsortium. Traditionally, bidders in an auction can only win if theycan personally secure sufficient funds to cover a winning bid. Themethod described in U.S. Pat. No. 5,794,219 overcomes this disadvantageby allowing the accumulation of smaller funds.

Unfortunately, this system is of limited application to joint giftgivers, as appropriate gifts are not often offered for sale at auction.Gifts are usually purchased in a retail rather than an auctionenvironment. In retail sales, the price is generally set by the vendorand is usually not negotiable, whereas in an auction environment, theprice is largely determined by the highest bidding purchaser. The systemdescribed in U.S. Pat. No. 5,794,219 does not describe how to accumulatethe individual contributions where the price is set. In suchcircumstances, it is desirable for the system to ensure that the totalcontributions of the joint purchasers does not exceed the price of theitem, and that the joint purchasers are satisfied with the relativesizes of their individual contributions.

The second system in this category is described in International PatentPublication No. WO 01/29787, entitled “System and Method forAccumulating Individual Gifts to Create a Group Gift”, byGiftcertificates.com, Inc, and is considered to be the closest prior artto the present invention. This document describes a system forautomating the task of accumulating a group gift to be donated to arecipient where the item purchased is a gift certificate, electronicvoucher, or negotiable instrument such as a bank cheque. The systemworks when a person, referred to as the promoter, accesses a softwareapplication via a network to initiate a “gift campaign”. A gift campaignis defined as the task of contacting a group of participants for thepurpose of soliciting donations or contributions to a group gift for thebenefit of a recipient.

The promoter identifies potential participants by an e-mail address andoptionally identifies a number of factors, including: the reason for thegift campaign (e.g. birthday); a suggested individual donation amount;and a total gift goal.

Finally, the promoter must identify a triggering event that will be usedto terminate the gift campaign. It is explained that the triggeringevent may be a particular date or time at which the gift campaign willterminate, or it may be another event such as the reaching of anaggregate gift amount. The software application then contacts each ofthe identified participants by e-mail.

The participants can respond by clicking on a Universal Resource Locator(URL), which prompts the software application to make a donation pageavailable to them. The donation page is described as including a fieldto allow the participant to input the amount of the individual donation.This field is described as taking the form of a drop-down menu havingseveral discrete donation amounts. The donation page also includes afield designed to accept credit card information from the participant.

It is explained that a triggering event terminates the gift campaign andthe service provider creates a gift certificate for presentation to therecipient. One of the embodiments explained involves the issue of adigital certificate that may be spent by the recipient at any of severalonline vendors who have a business relationship with the provider usingthe system described.

The Giftcertificates.com system addresses certain problems associatedwith traditional forms of joint purchasing. It avoids the need for theparticipants to get together to coordinate the purchase, and alleviatesthe need for one person to make a payment on behalf of the group,thereby preventing reimbursement problems.

Unfortunately, the system still presents a number of disadvantages forthose interested in making joint purchases to give as gifts. The chiefof these is that it does not provide a way to administer the jointpurchase of a specific gift (as opposed to a gift certificate). Whilegift certificates offer the advantage of the recipient being able tochoose a gift that he or she would like, they have the disadvantage ofbeing considered by some to be a less personal and less thoughtful gift.According to a survey by Forrester Research entitled “The Hidden Valuein Gift Sales” (Carrie A. Johnson, May 2001) only 5% of shoppers havebought a gift certificate online. 27% of consumers have not purchased agift certificate online because they don't give gift certificates ingeneral.

It would be possible for consumers to contribute funds towards a giftcertificate and then to choose a specific gift with the money raised.However this would be a two-stage process, which is somewhatinconvenient.

The purchase of gift certificates is similar to purchase at auctions inthat the price is not set by the vendor. It is determined by adding upthe individual contributions. As discussed above, where the price isset, joint purchasers of gifts have an interest in ensuring that nosurplus funds are paid to the vendor. Therefore it is desirable for thecomputer system to coordinate the contributions so that they add up tothe price of the chosen items. Where a gift certificate is chosen, thetotal amount of the gift is not crucial to the sale. A gift certificatefor the accumulated amount can be issued whenever the nominated timeexpires. Further if the triggering event is a total amount, it does notmatter if the combined total of the contributions has exceeded thisamount, because the excess goes to the recipient, who can spend it onthe gift. Where a specific gift is subsequently chosen by the giftrecipient when redeeming the gift certificate, any contributions made inexcess of the price of the item purchased must be disposed of in someway. Conversely, where a specific gift is being purchased jointly, theremust be a way of dealing with contributions made by participants whenthe price of the items has not been reached. For example, if a giftcosts $100, but the gift campaign fails because only $80 can be raisedfrom amongst the joint purchasers, there must be a way of refunding the$80 to the relevant people, or of ensuring there has been no transfer inthese circumstances. Unfortunately, the system described in PatentPublication No. WO 01/29787 does not address such problems.

Often the purchasers have an interest, not just in completing thepurchase, but also in ensuring they are satisfied with the relativesizes of their individual contributions. Joint purchasers may want topay equal portions. Alternatively, some people may want to pay a higherportion than others, perhaps due to having a closer relationship withthe gift recipient, or more funds to contribute. TheGiftcertificates.com system does not provide a mechanism for assistingthe purchasers in this way.

The reference to any prior art in this specification is not, and shouldnot be taken as, an acknowledgment or any form of suggestion that thatprior art forms part of the common general knowledge in Australia.

C. SUMMARY OF THE INVENTION

There is a need for a system for coordinating the low volume, jointpurchase of specific gifts where the total price is set by the vendorwhich:

-   -   does not require the joint purchasers to come together to        coordinate the purchase;    -   assists each joint purchaser to have a say in the selection of        the gift;    -   does not require one person to pay the supplier on behalf of the        group, and ensures that no person has difficulties in being        reimbursed by the others;    -   ensures that each person pays the correct or agreed amount;    -   enables each joint purchaser to obtain the rewards program        points associated with his or her portion of the purchase;    -   does not require membership of the system before it can be used;    -   allows the joint purchase to be effected in only one stage;    -   automatically keeps track of the payments by or between the        group members;    -   ensures that the total contributions do not exceed the price of        the gift;    -   ensures there is no value transfer from the purchasers to the        vendor until the purchase has been judged to be successful;    -   assists the joint purchasers to pay appropriate proportions of        the overall purchase; and which    -   assists the vendor by identifying that the proposed purchase is        a gift, and identifying the people who are participating in the        purchase.

Embodiments of the present invention attempt to provide one or more ofthe above features.

Advantageously, if the vendor knows the purchase is a gift, it caninclude a complimentary item in the package, or a greeting card and someinformation about its business or products when the gift is delivered.Thus the difficult and expensive tasks of identifying a potentialcustomer in the vendor's target market, and of mailing promotional itemsand information have been performed in the time of, and at the expenseof, a customer. Further, the Vendor can reward the Coordinator fororganising the gift by giving discounts on future purchases or otherincentives. This may serve to encourage further purchases (gifts andnon-gifts). Lastly, in one embodiment of the invention, the Participantssignify their consent to join in by visiting the vendor's web site andproviding their credit card details. This provides the vendor with anopportunity to provide these potential customers with information thatwill encourage them to make further purchases in the future (e.g.specials, promotional material etc).

An exemplary embodiment of the present invention provides a retailingmethod executable by a computer system, including the steps of:

-   -   sending a page to a prospective purchaser in response to a        request, said page being associated with a specific product;    -   receiving a purchase proposal from said prospective purchaser        for direct purchase of said product at a fixed price, the        purchase proposal including identifier information of persons        nominated by the prospective purchaser and purchase term        information selected at least in part by the prospective        purchaser, said nominated persons being nominated to contribute        to purchase of said product at said fixed price.

The present invention further provides a computer system for executing aretailing method, including:

means for sending a page to a prospective purchaser in response to arequest, said page being associated with a specific product;

means for receiving a purchase proposal from said prospective purchaserfor direct purchase of said product at a fixed price, the purchaseproposal including identifier information of persons nominated by theprospective purchaser and purchase term information selected at least inpart by the prospective purchaser, said nominated persons beingnominated to contribute to purchase of said product at said fixed price.

The exemplary embodiment of the present invention further provides aretail purchasing method executable by a computer system, including thesteps of:

-   -   receiving at said computer system a page in response to a        request therefor, said page being associated with a specific        product;    -   creating a purchase proposal for direct purchase of said product        at a fixed price using said computer system, the purchase        proposal including identifier information of persons nominated        by a prospective purchaser and purchase term information        selected at least in part by the prospective purchaser, said        nominated persons being nominated to contribute to purchase of        said product at said fixed price; and    -   submitting said purchase proposal to a retailer system.

The exemplary embodiment of the present invention further provides aretailing method executable by a computer system, including:

-   -   receiving a purchase proposal from a prospective purchaser for        direct purchase of a specific product at a fixed price, the        purchase proposal including identifier information of persons        nominated by the prospective purchaser and purchase term        information selected at least in part by the prospective        purchaser, said nominated persons being nominated to contribute        to purchase of said product at said fixed price.

The exemplary embodiment of the present invention further providescomputer readable storage having stored thereon program instructionswhich, when executed by a computer, cause the computer to perform thesteps of the above methods. The present invention also provides computersoftware for performing the steps of the above methods.

The exemplary embodiment of the present invention generally relates to asystem and method for Pooled Electronic Purchasing using a server systemand one or more client systems. It addresses or ameliorates one or moreof the problems associated with jointly purchasing specific gifts thatare encountered when using traditional methods, and the known demandaggregation and donation accumulation systems through:

-   -   the selection of a specific item or items where the price is set        by the vendor using delivery information specified by a customer        (referred to as the Coordinator);    -   the interactive establishment on a server system of a (logically        consistent) standing offer (known as a PEP Proposal) to buy one        or more chosen items on certain terms and conditions (the        Purchase Terms) as part of a single purchase order;    -   the assignment of a unique identifier by the server system to        that PEP Proposal;    -   the communication of the PEP Proposal to a plurality of        potential participants (Invitees) who use one or more client        systems;    -   the automatic evaluation and administration of the Invitees'        responses by the server system, which ensures those responses        are consistent with the terms of the PEP Proposal; and    -   the completion of the purchase in the event that the terms of        the PEP Proposal are satisfied, and the termination of the offer        in the event that they are not.

The preferred embodiment of the present invention enables customers toestablish purchase terms, interactively with the server system, whichensure that the correct amount will be raised (i.e. there will be nosurplus or shortfall) and that the participants will contributeappropriate amounts to the overall total through the use of variouscontribution methods.

Embodiments of the invention employ various evaluation mechanisms tocheck the purchase terms for logical errors that will prevent them frombeing fulfilled. Logically inconsistent purchase terms are not allowedto proceed, and the system assists the customers to remove logicalflaws.

The exemplary embodiment of the invention preferably provides eachInvitee an opportunity to view and approve the suggested purchase itemor items before making the purchase, and ensures that acceptances areconsistent with the Purchase Terms.

The preferred embodiment allows participants to contribute theirpayments individually by using their own client systems, and enables thetransfer of value from the customers to the vendor to be delayed until asufficient number of people have committed to purchase the item or itemsin accordance with the Purchase Terms.

One embodiment assesses the progress of the PEP Proposal through the useof a series of algorithms which enable it to identify whether thePurchase Terms have been: completed successfully, are unsuccessful, orcannot be successful. Lastly it coordinates the administration of ordersand assists in the delivery of the items once purchased.

Embodiments of the invention are generally implemented in software andinstalled on a server system of a retailer who already has an electroniccommerce portal established for selling their products or services. Theperformance of the invention in this aspect is accordingly effected bythe retailer's server system. In another aspect of the invention, thesoftware may be installed and executed by a server system not belongingto a retailer. In another aspect, the performance of the inventionresides in the purchasing steps executed by a purchaser (also termedherein the Coordinator or prospective purchaser or proposal originator)who interfaces with the retailer's server to conduct the pooledpurchasing. Although the software for enabling the purchaser to createthe purchase proposal resides on the server system, the inventiveinteraction of the purchaser's computer system with the server iseffected and enabled by that software.

D. BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional block diagram of one network environment which isparticularly well suited to the present invention.

FIG. 2 is a simplified flow diagram providing an overview of oneembodiment of the present invention.

FIG. 3 is a simplified block diagram showing the elements that might bepresent on a typical web page displaying an item for sale.

FIG. 4 is a flow diagram illustrating the process by which the serversystem can assist the Coordinator to establish the Purchase Terms for anew PEP Proposal.

FIGS. 5A, 5B and 5C are simplified block diagrams showing the elementsthat might be present on typical web pages that assist the Coordinatorto establish logically consistent Purchase Terms when differentcontribution methods have been selected.

FIGS. 6A, 6B and 6C are flow diagrams illustrating algorithms that canbe used to check whether the Purchase Terms established by theCoordinator are logically consistent for different contribution methods.

FIG. 7 is a flow diagram providing an overview of how the Vendor'sserver system handles the responses and non-responses from the Inviteesin one embodiment.

FIGS. 8A, 8B and 8C are simplified block diagrams showing the elementsof possible individual response pages under different Purchase Termscenarios.

FIG. 9 is a block diagram showing a possible payment acceptance pagethat can be used for alternative Purchase Term combinations in oneembodiment.

FIGS. 10A, 10B and 10C are flow diagrams illustrating the watchdogalgorithms designed to determine whether a PEP Proposal is successful,unsuccessful or can no longer be successful.

E. DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

1. Network environment

FIG. 1 is a functional block diagram of one network environment which isparticularly well suited to the present invention. The diagram depicts aVendor's System 101, which offers a pooled electronic purchasing serviceto the world at large. The Vendor's System is comprised of the serverarchitecture 106 responsible for managing and processing the informationrequired by the present invention. It also includes a web site 102,which contains the vendor's general e-commerce pages 105 and the pagesassociated with the present invention 109. Also located on the serversystem are three databases:

-   (i) an inventory database 103 which contains information regarding    the levels of stock and ordering requirements and which may allocate    particular items to particular customer orders;-   (ii) a PEP Proposal database 107 which contains the non-financial    information relating to each of the PEP Proposals, including the    details of the Invitees, the Purchase Terms, the administrative    details, and records of the Invitees' responses; and-   (iii) a payment database which may include credit card and other    details (see below) 110.

Examples of database systems that can be used by the Vendor's System 101to maintain the information include Microsoft Corporation's Access7.0/2000 or Oracle 9i by Oracle Corporation. The information containedin such databases are manipulated by software applications created usingserver-side scripting languages such as Microsoft's ASP, AllaireCorporation's Coldfusion. The Vendor's System 101 may be more complexthan depicted (for example, the database may be distributed across manyservers). Alternatively, it may be simpler than the one depicted (forexample, it might combine the three separate databases into a singlesystem).

In FIG. 1 two customers, the Coordinator (who initiates the PEP) and theInvitee, use their respective client systems (104 and 108) to access theVendor's web site 102 via communications networks. Although only twocustomers are depicted here, there is no limit on the number ofcustomers who can participate in a Pooled Electronic Purchase.

The present invention can utilise many different types of communicationsnetworks. For example, a proprietary Wide Area Network (WAN) or a publicWAN such as the Internet may be used. These networks typically employvarious protocols such as the HyperText Transfer Protocol (HTTP),Extensible Markup Language (XML), Voice over Internet Protocol (VolP)and the Internet Protocol/Transfer Control Protocol (TCP/IP) to transferinformation between remote computer systems—often through the use ofservices such as the World Wide Web and email.

The present invention might also utilise wireless networks, includingthose utilising Global System for Mobile (GSM), Code Division MultipleAccess (CDMA) or Time Division Multiple Access technology, and theWireless Application Protocol (WAP). The present system and method canutilise any, or any combination of, such communications networks. Assuch, although the client systems (104 and 108) are represented as beingpersonal computer systems, any electronic device capable of interfacingwith a communications network may be used, including personal digitalassistants (Palm pilots, Handspring Visors and the like) and mobilephones etc.

Where the client system is a personal computer, that system may includea web browser such as Navigator 6.0 by Netscape or Internet Explorer byMicrosoft Corporation that can be used to display HyperText MarkupLanguage (HTML) documents sent by the server system. Such browsers canutilise client-side scripting languages such as Javascript and VB Scriptto traps user errors on the client machine, and to manipulate the clientdocument before being sent back to the server. This is more efficientthan relying on server side scripting only. The Vendor's System receivesHTTP requests to access web pages on the web site identified by URLs andprovides the web pages to the client systems in response. Informationdistribution is controlled through the use of a server-side scriptinglanguage such as Microsoft Corporation's ASP or Allaire Corporation'sColdfusion. The Coordinator, the Invitees and (later) the Participantswould have access to certain portions of the information contained onthe inventory database 103 and the PEP Proposal database 107 viaPEP-related pages on the vendor's web site 109 such as the IndividualResponse Pages and the Status Pages (discussed below). This informationmay be password protected.

The present invention administers the transfer of value from thecustomers to the vendor in the event that the PEP Proposal is completed,and the goods and services are purchased jointly. The value transferseffected using the present invention can be made using a variety ofelectronic payment systems, including credit cards, debit cards, chargecards, smart cards, digital or electronic cash or cheques. However, forthe sake of convenience, the present invention is described using creditand charge card payment systems as examples. As such, FIG. 1 depicts anumber of systems that may be used to administer the transfer of valuefrom the Coordinator 104 and the Invitee 108 to the Vendor 101. Theseinclude the Coordinator's Bank System 111, the Invitee's Bank System114, the Vendor's Acquiring Bank System 113 and the Gateway System 112.The function of each of these entities is described in more detail underthe heading “payment administration” at section 6 below.

In an alternative embodiment, the invention may be performed through aserver separate to the vendor's system. In this case, the PEPfunctionality of server 106 described above is handled by a separate PEPserver (not shown) which provides the PEP-related pages 109.Additionally, the payment database 110 and PEP proposal database 107interfaces directly with the PEP server, which in turn interfaces withthe vendor system 101. In this embodiment, the PEP server interfaceswith the gateway system 112 to effect payment from the participants. ThePEP server then provides delivery information (if necessary) to thevendor system 101 and pays the purchase price to the vendor, less asmall commission or flat fee. This embodiment otherwise generallyoperates similarly to the embodiment shown in, and described in relationto, FIG. 1.

2. Overview

FIG. 2 is a simplified flow diagram providing an overview of theprocess. The process begins when the Coordinator visits a vendor's website, selects a specific item or items to be purchased jointly andsignifies a wish to establish a PEP proposal 201. A PEP Proposal is astanding offer to purchase a specific item or items jointly. Such itemsmay be any good or service where the price is set by the Vendor ratherthan the Participants.

FIG. 3 illustrates an example of a web page that would be sent to theCoordinator's client system by the vendor's server system in this partof the process 201. There is a summary description of the item 301, adetailed description of the item 305, and an option to commence aconventional “shopping cart” purchase 302. A customer commences a PooledElectronic Purchase by clicking on the dedicated button 303. A buttonenabling the Coordinator to obtain an explanation of the invention mightalso be provided 304. One skilled in the art would be familiar with theuse of such buttons on web pages and would appreciate that the varioussections described can be omitted or rearranged or adapted in variousways.

A Coordinator accessing the present invention by clicking on therelevant option 303 would be taken to a shopping cart-type web page,where he or she would be given the opportunity to confirm the selection,or to continue shopping. Such a web page would utilise conventionalshopping cart technology and is therefore not described here.

After the Coordinator is satisfied with the item or items chosen, he orshe then indicates an intention to proceed with a PEP proposal. Theserver system 106 (or alternatively a separate PEP server) assigns atemporary code to this potential PEP Proposal and takes the Coordinatorthrough a series of questions to establish the Purchase Terms at step202. Under this embodiment, the Purchase Terms will include details suchas the amount that each Invitee will be asked to contribute, as well asadministrative details such as the name of the recipient and shipmentinformation etc. FIG. 4 is a detailed flow diagram illustrating theprocess by which the server system can assist the Coordinator toestablish the Purchase Terms in one embodiment of the invention. FIGS.5A, 5B and 5C are simplified block diagrams depicting web pages thatmight be downloaded by the Coordinator's client system 104 at step 202.

The server system then uses a series of algorithms to check that thePurchase Terms are logically consistent at step 203. Purchase Terms arelogically consistent if a purchase will result when their terms aresatisfied. Conversely, Purchase Terms are logically inconsistent if apurchase will not result even though they are satisfied. It is desirablefor the Vendor's System to ensure that the Purchase Terms are logicallyconsistent before it is allowed to proceed. This ensures that theInvitees and the Vendor's System do not waste their time and resourcesresponding to a PEP Proposal that cannot result in the purchase of agift. If the Purchase terms are not logically consistent (203=no), theserver system asks the Coordinator to re-enter them at step 202, and mayassist him or her in this process. If the Purchase Terms are logicallyconsistent (203=yes), a unique identifier is assigned to the PEPProposal and stored in the relevant database 107 (not illustrated) andthe process is allowed to proceed at step 205. The algorithms used tocheck the logical consistency of the Purchase Terms, depicted in FIGS.6A, 6B and 6C, and are discussed in greater detail in section 3(d).

The process proceeds when the PEP Proposal is published to the Inviteesnominated by the Coordinator at step 204. Depending upon thecircumstances of the purchase, the PEP Proposal might be publisheddirectly or indirectly to the Invitees. Where the purchase is between agroup of strangers (such as the purchase of equipment for charitablepurposes on behalf of an aid agency) the PEP Proposal might be publishedusing indirect marketing methods such as print or web advertising. Wherethe purchase is between a group of friends, the PEP Proposal would bepublished directly to the Invitees, perhaps by e-mail or by (ShortMessage Service) SMS text to a cellular mobile phone utilisingtechnologies such as GSM, CDMA or TDMA.

The Invitees then respond to the PEP Proposal, and the server systemstores their details pending evaluation at step 208. Where the PEPProposal has been communicated to the Invitees by email at step 205, theInvitees could respond by clicking on a hyperlink to a unique IndividualResponse Page on the server system which has been inserted into theemail. This Individual Response Page could explain the nominatedPurchase Terms to each Invitee, and ask them to agree to these terms.FIGS. 8A, 8B and 8C provide examples of possible Individual ResponsePages in one embodiment of the invention, and these diagrams arediscussed in greater detail in section 4 below.

Broadly speaking, those Invitees who wish to participate (therebybecoming Participants) will signify their agreement to do so and thenprovide their credit card or other electronic payment system details.These details are stored by the vendor, or a third party and the vendorat step 208. It is necessary for the server system to ensure that theacceptances provided by the Participants are consistent with, or fallwithin, the Purchase Terms. FIG. 9 provides an example of a paymentacceptance page that can be used to achieve this goal during this partof the process, and this is discussed below.

The server system periodically evaluates the Invitee responses andnon-responses by using a series of watchdog algorithms. In the preferredembodiment of the present invention, this is not a continuous process,but is done upon the occurrence of periodic events, such as the receiptof each new Invitee response, or at the change of date. Thealgorithms—which are illustrated in detail in FIGS. 10A, 10B and10C—will vary according to the Contribution Method chosen by theCoordinator. Their chief purpose is to determine whether the terms ofthe PEP Proposal have been met, but they are also designed to ensurethat the PEP Proposal is optimised for the Participants, and to ensureit is terminated at an appropriate time. These concepts are discussed ingreater detail in section 5 below.

Where the terms of a PEP Proposal have not been met (207=no), and thereis no possibility that they can be met (206=no) the PEP Proposalterminates at or before the cut-off date at step 206 (although theremight be an option for the Coordinator to extend the proposal or torecommence another proposal along similar lines). The Participants areable to check the progress of the process at any stage by downloading astatus page from the server system.

Where the terms of the PEP Proposal have been met (207=yes), and theterms have been optimised for the Participants (212=yes), confirmatione-mails are sent to the Participants at step 211, and there is a valuetransfer to the vendor at step 210. There are a number of ways in whichthe vendor could store and deal with the payment details provided bycustomers and the progress of orders taken using the present invention.The vendor would need to address a number of problems that couldpotentially arise if the standard ‘real time’ authorisation proceduresfor credit cards is used. If an Invitee's credit card is charged as soonas the Invitee provides his or her details, this amount would need to berefunded if the Purchase Terms are not met by the cut-off date at step205. If the Invitee's credit card is not charged until the PurchaseTerms are met at step 211 it is possible that authorisation will bewithheld by the Invitee's bank, perhaps because the Invitee's creditlimit has been exceeded at that point in time or because the credit cardhas expired. In the preferred embodiment of the present invention, thetransfer of value is effected using the mechanism of direct debitpre-authorised payments. This allows the vendor to place a “hold” over aspecified portion of each Participant's credit limit pending thecompletion (successful or otherwise) of the PEP Proposal. If the PEPProposal is completed successfully, the value transfer occurs at step201. If the PEP Proposal is not completed successfully at step 205, thecredit card is never charged, and the hold expires. This avoids thepotential problems identified above.

Once there has been a value transfer, the selected item or items can bedelivered automatically at step 209. This step is discussed in moredetail at section 7 below.

3. Establishing the Purchase Terms

FIG. 4 is a detailed flow diagram illustrating a process by which theserver system can assist the Coordinator to establish logical PurchaseTerms interactively. Those familiar with the art will appreciate thatthe process depicted in FIG. 4 can be undertaken in one or more steps bythe server system. Further, with one exception, the information capturedby the server system during this stage can be captured in a differentorder from that depicted.

In the embodiment described below, the server system assists theCoordinator to establish the Purchase Terms by sending four separate webpages to the Coordinator's client system. The content of these pageswill vary depending upon the various selections made by the Coordinatorduring the process.

a) Administrative details

The first page sent to the Coordinator at this stage of the processelicits the administrative details at step 401. The total cost of thepurchase must be ascertained by the completion of this step. The totalcost includes not only the price of the chosen item or items, but alsoany associated taxes and imposts, delivery costs, greeting card andwrapping charges. Ascertainment of the total cost enables the correctdivision of the purchase between the Participants. Therefore, it isnecessary to ascertain:

-   i) the address for delivery;-   ii) the last delivery date, or delivery method (overnight courier,    ordinary mail, or pick up etc);-   iii) whether a card is to be delivered with the gift and    (optionally) the choice of card; and-   iv) whether any wrapping is required, and the choice and cost of    that wrapping.

It is desirable for the server system to include a database withinformation on the various delivery charges, and taxes and impostsassociated with deliveries into specific regions, provinces, states orcountries. These additional charges could be added automatically to thetotal price. However, this information may not be readily available, orit may be difficult to keep such information up to date. If the vendor'ssystem cannot access this information immediately (which is desirable)there are two alternatives. The first involves obtaining a personalundertaking from the Coordinator to pay for additional unforeseencharges. The second involves waiting for this information to becomeavailable.

In addition to the above information, the server system may optionallyseek the following information from the Coordinator:

-   v) the details of the occasion (i.e. Birthday, Christmas, Wedding    etc);-   vi) the cut-off date for the Invitees' responses;-   vii) whether the status page is to be password protected, and if so,    the password; and-   viii) the name of the ultimate recipient.

As this information can all be obtained, by utilising conventionalweb-based know how, this page is not described or depicted here.

b) Contribution methods

Once the total price has been ascertained, the server system thenascertains which contribution method is preferred by sending a secondpage to the Coordinator at step 402. A Contribution Method is a methodfor dividing up the exact purchase price amongst the Participants. Inthe preferred embodiment of the present invention, there are threedifferent Contribution Methods. These allow for payments:

-   (i) in equal shares (step 403). This is where two Participants pay    half each, three pay thirds, four pay quarters, and so on;-   (ii) in unequal amounts specified by the Coordinator (step 404). The    individual contributions might be of any amount, providing that    together they add up to the total price. For example, Participants    A, B and C might be asked to contribute $40, $20 and $20    respectively, or perhaps $40, $25 and $15 towards an $80 item;-   (iii) in unequal amounts chosen by the Invitees (step 405): Each    Invitee is free to nominate the sum they would like to contribute.    In one embodiment of the invention, the PEP Proposal will end    successfully as soon as the required amount is raised.

The Vendor's System can use these Contribution Methods to assist theCoordinator to set the individual contributions, while at the same timeensuring that these contributions exactly add up to the total purchaseprice.

(i) Equal shares

Where the Coordinator specifies that the Invitees will be asked tocontribute in equal shares at step 403, he or she will then be asked howmany people must participate in the purchase at step 406. Thisinformation will determine the amount (or a range of amounts) that eachParticipant will ultimately be liable to pay. The Coordinator cannominate a set number, maximum, minimum, or maximum and minimum numberof Participants. Where a set number of Participants has been selected,the server system can calculate the exact amount of each Participant'scontribution in advance. Where the Coordinator specifies a minimum,maximum or minimum and maximum number of Participants, the server systemwill calculate a range of amounts that would be payable by theParticipants.

The Coordinator is then asked to enter the Invitees' contact details atstep 409. These details may include the name and e-mail address ormobile phone number. The mobile phone number may be used by the serversystem to contact Invitees using an SMS text through their mobilephones. Initially, this information is necessary to ensure that theInvitees receive the Coordinator's invitation.

In the preferred embodiment, the server system will then ask whetherthese Invitees can be substituted (i.e. replaced), or whether additionalpeople can be asked to participate in the purchase at a later time atstep 412.

The server system must ensure that the Purchase Terms are internallyconsistent. For example, where a minimum number of five Invitees areasked to contribute equal amounts at step 406, the Coordinator must havenominated at least five invitees at step 412, or else allowed additionalinvitees to be added at a later stage at step 412. The server systemevaluates the Purchase Terms using the relevant logical evaluationalgorithm at step 412. This algorithm is depicted in detail at FIG. 6Aand is discussed in detail below.

If the purchase terms are logically consistent, the Coordinator confirmsthem at step 422.

FIG. 5A depicts a web page that might be sent to the Coordinator in oneembodiment. It contains elements that enable the server system toascertain personal and contact details of the Coordinator (fields 501,502, 503 and 504). The server system then asks the Coordinator whetherhe or she will become a Participant (505 and 506). By choosing theappropriate radio button 506, the Coordinator does not need to enter hisor her own name at the next stage 507. The Coordinator then enters thefirst name 513, last name 514 and email address 515 of each Invitee. Inthe embodiment depicted, the server system can transfer the enteredinformation to the entry box below 517 using a client-side script (suchas Java Script or VB Script) when the Coordinator clicks on the “add”button at 516. The Coordinator can amend any errors in the informationadded by the Coordinator selecting the “Edit” button 518. If theCoordinator changes her mind, the Invitees can be removed 519. TheCoordinator is also given an option to view his or her address book 520.This option is discussed in detail in section 3(c) below. Options aregiven to substitute (521 and 522) and to add Invitees (523 and 524).There is an option to obtain answers to possible questions 526, and togo back to the first page 525 or to continue to the next 527. Oneskilled in the art will be familiar with the use of radio buttons andclient-side scripts.

(ii) Unequal amounts specified by the Coordinator

Where the Participants contribute amounts that are specified by theCoordinator at step 404, he or she is asked to enter the Invitees'contact information at step 407. A number of methods for entering theseamounts are discussed in paragraph 3(c) below.

The Coordinator enters the amounts that are to be paid by each Inviteeat step 407.

The Coordinator is asked whether the named Invitees can be substitutedat a later stage 413. Under this Contribution Method, it is possible toadd new Invitees providing that the individual, contribution amounts addup to the total price. This may be achieved by (for example) splittingone or more of the original contribution amounts among the additionalInvitees. However, for present purposes, the only option presented inFIG. 4 is the substitution of the Invitees, with the new Invitee payingthe amount nominated for the Invitee that is being replaced at step 413.This is a much simpler option.

The amounts to be paid by each Invitee must add up to the total price,and this is verified by an evaluation algorithm at step 417. Thisalgorithm is illustrated in detail in FIG. 6B. Once the Purchase Termshave been assessed and approved by this algorithm, the Coordinatorconfirms the Purchase Terms at step 422.

FIG. 5B depicts a web page that might be sent to the Coordinator in oneembodiment of the invention. Similar to FIG. 5A, it contains elementsthat enable the server system to ascertain personal and contact detailsof the Coordinator (fields 528, 529, 530 and 531). The Coordinator isasked whether he or she will become a Participant (532 and 533). Bychoosing the appropriate radio button 533, the Coordinator does not needto enter his or her own name at the next stage 534. The Coordinator thenenters the first name 535, last name 536 and email address 537 of eachInvitee. In contrast to FIG. 5A, the Coordinator is also asked to enterthe suggested individual contribution amount for each named Invitee 538.The server system transfers the entered information to the entry boxbelow 540 when the Coordinator clicks on the “add” button 539. If thereare errors in the information added, this can be amended by theCoordinator selecting the “Edit” button 542. If the Coordinator changeshis or her mind while establishing the PEP Proposal, the Invitees can beremoved 543. This option is discussed in detail below. The Coordinatoris also given an option to view his or her address book 544. The enteredindividual contribution amounts 538 might be added up and displayed onthe web page 541, perhaps with a comparison of the total price. If theCoordinator is unable to ensure that the total suggested contributionsadd up to the total price, he or she may opt to have the server systemsuggest contribution amounts instead 545. Options are also given tosubstitute Invitees (546 and 547), to obtain answers to possiblequestions 549, and to go back to the first page 548 or to continue tothe next 550.

(iii) Unspecified amounts chosen by the Invitees'

Where the Participants are asked to contribute amounts of their choice405 the Coordinator would be asked to enter the Invitees' contactinformation 408 and to stipulate whether these people can be substitutedor whether additional people can be added 411.

The Coordinator is asked whether there will be a minimum contribution414, and if there is, to select that amount 415. He or she is also askedwhether there will be a maximum contribution 418, and if there is, toselect that amount 419.

It is possible that the Coordinator might try to stipulate a maximumindividual contribution but an insufficient number of Invitees to raisethe total purchase price. This would render the PEP Proposal incapableof being completed (i.e. it would be logically inconsistent).Accordingly, the Purchase Terms must be assessed by a logical evaluationalgorithm 421. This algorithm is depicted in FIG. 5C and is discussed indetail below.

The process culminates with the Coordinator confirming the PurchaseTerms 421.

FIG. 5C depicts a web page that might be sent to the Coordinator in oneembodiment of the invention. As with FIGS. 5A and 5B, it containselements that enable the server system to ascertain personal and contactdetails of the Coordinator (551, 552, 503 and 554). The server systemthen asks the Coordinator whether he or she will become a Participant(555 and 556). By choosing the appropriate radio button 556, theCoordinator need does not need to enter his or her own name at the nextstage 557. The Coordinator then enters the first name 558, last name 559and email address 560. The server system transfers the enteredinformation to the entry box below 562. If there are errors in theinformation added, this can be edited by the Coordinator selecting the“Edit” button 563. If the Coordinator changes her mind, the Invitees canbe removed 564. The Coordinator is also given an option to view his orher address book 565. This option is discussed in detail below. Optionsare given to substitute (566 and 567) and to add Invitees (568 and 569).There is an option to obtain answers to possible questions 571, and togo back to the first page 570 or to continue to the next 572.

c) Entering the Invitees' details

Under each of the scenarios outlined above, the Coordinator is asked toprovide the contact information for each of the Invitees to the serversystem (407, 408 and 409). The precise nature of this contactinformation will vary according to the technology used by the serversystem and the communication method selected by the Coordinator. Ane-mail might be sent to the Invitees, who could download that messageusing a desktop client system or a WAP enabled portable device. In thesecases, the contact information will include the Invitees' e-mailaddresses. Another way in which the PEP Proposal may be communicated tothe Invitees is through the use of SMS text to a cellular mobile phone.In these cases, the Invitees' contact information will include therelevant telephone numbers. The server system might offer one of, or acombination of, such methods.

As discussed above, the Coordinator might enter each Invitee name andaddress manually (513-516, 535-539, 558-561). This has the disadvantageof being a relatively slow process. Further, it is possible that theCoordinator could enter incorrect details by mistake. The server systemcould assist by up-loading the Coordinator's personal email address bookdirectly from his or her dedicated e-mail program at the request of theCoordinator (520, 544, 565). It would do so by downloading aself-executing program that searches for the address book fileassociated with the Coordinator's e-mail program, and then up-loadingthat file to the server system. The addresses could then be displayed ona new web page. The Coordinator could indicate who will be asked tocontribute by ticking the relevant contact information. Alternatively,Coordinators might store lists of contact information for their friendsand relatives specifically for use in conjunction with the presentsystem and method. This information might be stored on their own clientsystems or on remote server systems (either the vendor's or anothersystem), ready to be accessed when desired. Each of these alternativemethods has the advantage of being faster and more accurate than manualentry.

d) Logical evaluation algorithms

As discussed, it is important for the Server System to ensure that thePurchase Terms established by the Coordinator are logically consistent.This ensures that the Invitees and the Vendor's System do not wastetheir time and resources responding to a PEP Proposal that cannot resultin the purchase of a gift.

The evaluation algorithms would be implemented by the server systemusing a server-based scripting language, possibly in conjunction with aclient-based script. Those skilled in the art will know that theelements of the evaluation algorithms can be employed in a differentorder from that shown.

(i) Evaluation algorithm for purchase in equal shares 416

Where the Coordinator has specified that the Invitees will be asked tocontribute in equal shares at step 403, he or she must specify therequired number of Participants at step 406. Where the number ofInvitees nominated by the Coordinator is greater than the set or minimumnumber of Participants nominated at step 406, it is clear that the PEPProposal has a chance of being completed successfully (i.e. it islogically consistent). If this is not the case, it is possible that thePEP Proposal cannot succeed (i.e. the Purchase Terms may be logicallyinconsistent).

The Logical Evaluation Algorithm depicted in FIG. 6A is designed toassess the logical consistency (or otherwise) of the Purchase Terms inthese circumstances 601.

The server system determines whether the total number of Invitees(I_(T)) is greater than or equal to the set or minimum number ofrequired Participants (Part_(min)) (specified at 406) at step 602. If itis (i.e. if 602=yes), the Purchase Terms are logically consistent, andthe Coordinator is asked to proceed to step 603 by confirming thePurchase Terms. If not (i.e. if 602=no), the Purchase Terms might belogically inconsistent. The server system then determines whetheradditional Invitees can be added at step 605 (as specified by theCoordinator at 412). If additional people can be invited (i.e. if605=yes), the Purchase Terms can be met as long as they are invitedbefore the cut-off date. In other words, the Coordinator might havespecified that a minimum of four people must participate in thepurchase, but may have named only three Invitees. This would not befatal to the PEP Proposal if additional people are invited before thecut-off date and four of them agree to participate. The server systemexplains the implications of the chosen Purchase Terms to theCoordinator at step 606, who would then be given the option to add moreInvitees at step 604, reduce the minimum number of Invitees at step 608,or proceed without making any changes at step 607.

After choosing one of these options, the Coordinator is asked to proceedto step 603 where the Purchase Terms are confirmed.

Where the number of Invitees is less than the minimum required number ofparticipants (602=no), and where there is no provision for additionalInvitees to be added (605=no), the Purchase Terms are logicallyinconsistent, and this must be explained to the Coordinator at step 609.The Coordinator is then given the opportunity to rectify the PurchaseTerms by adding more Invitees immediately at step 610, allowingadditional people to be invited at a later stage at step 611 or reducingthe required minimum number of Invitees at step 612. If the Coordinatortakes one or more of these options, the new Purchase Terms arere-evaluated by the logical evaluation algorithm at step 602. On theother hand, the Coordinator may decide to start again 613, and in thiscase, he or she would be asked to choose a Contribution Method at step402.

(ii) Evaluation algorithm for purchase in unequal amounts specified bythe Coordinator 417

Where the purchase is to be made in unequal amounts specified by theCoordinator at step 404 different considerations determine whether thePurchase Terms are logically consistent or not. The Logical EvaluationAlgorithm depicted in FIG. 6B is designed to assess the logicalconsistency (or otherwise) of the Purchase Terms in these circumstances614.

Here, the server system must verify that the total price (P_(T)) isequal to the sum of the specified individual contributions (Σ[C(I₁) . .. C(I_(z))]) (where C(I₁)=the specified contribution for the firstInvitee and C(I_(z))=the specified contribution for the last Invitee) atstep 615. Where this is the case (i.e. 615=yes), the Purchase Terms arelogically consistent and the Coordinator is asked to proceed to step 616by confirming them.

Where the total price (P_(T)) does not equal the sum of the specifiedindividual contributions (Σ[C(I₁) . . . C(I_(z))]) (615=no), thePurchase Terms are logically inconsistent, and this must be explained tothe Coordinator at step 617. The Coordinator is then given theopportunity to re-enter the individual contribution amounts at step 618or have the server system suggest new amounts at step 619.

Where the server system is asked to suggest new individual contributionamounts at step 619 it could use a simple formula that suggests newamounts that add up to the total price which are based on thepercentages suggested by the original contribution amounts 621. Forexample, if the original contribution amount for the first Invitee(C(I₁)_(Original)) was equal to 10% of the sum of the specifiedindividual contributions (Σ[C(I₁) . . . C(I_(z))]) the server system cancalculate a new contribution amount for this Invitee by multiplying thetotal price (P_(T)) by 10%.

The Coordinator is then given options at step 622 either to accept thesuggested amounts at step 620 or to re-enter the individual contributionamounts manually at step 623. Wherever the Coordinator exercises theoption to re-enter the individual contribution amounts manually (623 or618), the server system assesses the new Purchase Terms afresh at step615.

(iii) Evaluation algorithm for purchase in unequal amounts chosen byInvitees 421

FIG. 6C illustrates a logical evaluation algorithm that can be used toassess the Purchase Terms where the purchase is to be made with amountschosen by the Invitees at step 625. The server system begins byascertaining whether the Coordinator has stipulated a maximumcontribution (C_(max)) (i.e. whether C_(max)>0) at step 626.

If there is no maximum contribution (i.e. if 626=no) the Purchase Termsare logically consistent, and the Coordinator proceeds by confirmingthem at step 628. If there is a maximum contribution (i.e. if 626=yes),the server system then ascertains whether this figure (C_(max))multiplied by the total number of Invitees (I_(T)) is less than thetotal price (P_(T)) 627. If the maximum amount that can possibly beraised from amongst the nominated Invitees (C_(max)×I_(T)) is greaterthan or equal to total price, the Purchase Terms are logicallyconsistent, and the Coordinator is asked to proceed by confirming themat step 628.

On the other hand, if the maximum amount that can possibly be raisedfrom amongst the nominated Invitees is less than the total price, (i.e.627=no), the server system then determines whether additional Inviteescan be added 630 (as specified by the Coordinator at 411). If additionalpeople can be invited (i.e. if 630=yes), the Purchase Terms can be metas long as they are invited to do so and they contribute to the giftbefore the cut-off date. In other words, the Coordinator might havespecified a maximum contribution of $20 and invited four people toparticipate in the purchase of a $100 gift. If a fifth person joins inand contributes the maximum amount, the PEP Proposal will be successful,but it can only be successful if more people are actually invited. Theserver system explains the implications of the chosen Purchase Terms tothe Coordinator at step 631, who would then be given the option to addmore Invitees immediately at step 629, reduce the minimum number ofInvitees at step 633 or proceed to step 632 without making any changes.

After choosing one of these options, the Coordinator is asked to proceedby confirming the Purchase Terms at step 628.

On the other hand, if the maximum amount that can possibly be raisedfrom amongst the nominated Invitees is less than the total price, (i.e.627=no), and additional Invitees cannot be added (639=no) the PurchaseTerms are not logically consistent and this must be explained to theCoordinator 634. The Coordinator is then given the opportunity torectify the Purchase Terms by adding more Invitees immediately at step635, allowing additional people to be invited at a later stage at step636 or increasing the maximum contribution at step 637. If theCoordinator takes one or more of these options, the new Purchase Termsare re-evaluated at step 626. On the other hand, the Coordinator maydecide to start again at step 638, and in this case, he or she would beasked to choose a Contribution Method at step 402.

e) Confirmation Pages

All of the processes described above culminate in a request for theCoordinator to.confirm the Purchase Terms (422). It is necessary toensure that the Coordinator clearly understands those terms beforeproceeding, as these will vary significantly depending upon the precisecombinations chosen. This is accomplished when the client systemdownloads a web page summarising all relevant details relating to thePurchase Terms and the Coordinator signifies a desire to proceed. Thisis a conventional part of electronic commerce, and is not detailed here.

f) Conclusion

The options for the establishment of the Purchase Terms outlined abovein Section 3 are merely examples taken from one embodiment of theinvention. Those familiar with the art would be aware that the inventionmight:

-   -   (a) be made less complex, through (for example):        -   (i) restricting the number of Contribution Methods made            available by the server system (e.g. allowing contributions            to be in equal shares or specified amounts only);        -   (ii) initially offering a basic choice of selections, and            only offering more advanced options after being asked to do            so by the Coordinator;        -   (iii) reducing the flexibility associated with the above            Contribution Methods (e.g. the server system might not allow            Invitees to be added or substituted, or where contributions            are made in equal shares, it might only allow set numbers of            Participants to participate); or    -   (b) be made more complex, through (for example):        -   (i) assisting people to reach a consensus regarding the            amounts of their contributions; or        -   (ii) allowing “hybrid” Contribution Methods (e.g. by            allowing part of the purchase price to be provided by some            of the Participants in equal shares, with the balance being            provided by Participants contributing amounts of their            choice).

The precise configuration of the invention may vary according to thelevel of sophistication required by vendors and customers.

It is also possible to obtain the required information in a differentorder from that shown in FIGS. 4 and 5A, 5B and 5C.

4. Administering the Invitee responses

Once the PEP Proposal has been established and published, the serversystem must administer the responses and non-responses from thoseInvitees. This process is depicted in FIG. 7. As illustrated in thatdiagram, the invitation is received by each of the Invitees (includingthe Coordinator where the Coordinator is to be one of the Participants)at step 701.

a) General

If an Invitee does nothing in response to the invitation at step 702, areminder would be sent to that person in advance of the cut-off date atstep 703. At that point the Invitee might still do nothing at step 704or choose to respond by contacting the server system at step 706. Wherethe Invitee has received his or her invitation in e-mail form, this maybe done by clicking a hyper-link to an individual response page at thevendor's web site. Where the invitation is delivered in SMS form, theInvitee may respond by contacting a call centre with direct access tosuch a page. If the Invitee still chooses to do nothing at that point atstep 704 the possibility of his or her involvement would cease as soonas it becomes clear that the Purchase Terms cannot be met, or if thecut-off date has been reached at step 705.

On the other hand, if the Invitee chooses at any time to respond byhyper-linking to an Individual Response Page at step 706, he or she mayeither decline the invitation at step 707 or accept it and provide therequested financial details at step 711. As discussed, the nature ofsuch details will vary according to the type of electronic paymentsystem used. For example, it may be in the form of credit card numbersand expiry dates, or information transmitted via a smart card or in anelectronic purse. If the Invitee declines the invitation at step 707,the server system may provide him or her with the opportunity to suggestsubstitute or additional Invitees at step 708. This opportunity willonly be provided where the Coordinator has previously enabled thisoption (411, 412, 413). The Invitee's involvement would then cease atthat point at step 709.

If the Invitee chooses to proceed by joining in at step 711, he or shemay also be provided with the opportunity to name additional Invitees incircumstances where the Coordinator had chosen to make this optionavailable (411, 412, 413) at step 712. The server system then evaluateswhether the Purchase Terms have been met (a process described in detailin section 5 below) at step 713. The Participant may then be referred toa status page for a summary of the progress of the PEP Proposal (seesection 4(d) below) at step 714. If the Purchase Terms are not met bythe cut-off date—in spite of that Invitee having agreed toparticipate—confirmation is sent at step 710, and that Invitee'sinvolvement ceases at that point at step 709. If the Purchase Terms aremet, confirmation is sent and a value transfer takes place at step 715.

b) Individual Response Pages

As discussed above, the Invitees may respond to their invitations byhyper-linking to individual response pages. If an Invitee agrees toparticipate in a joint purchase, he or she is entering into a contractnot only with the vendor, but also with the other Participants.Accordingly, it is important for each Invitee to understand the PurchaseTerms thoroughly so far as they relate to him or her. It is thereforedesirable that each response page be tailored to address the Inviteesindividually, and describe the Purchase Terms as simply and directly aspossible.

It would be possible for the individual response pages to correspond tothe contribution methods illustrated in FIG. 4. An alternative method isillustrated in FIGS. 8A, 8B and 8C, which provide examples of possibleIndividual Response Pages used for different Purchase Term combinationsin one embodiment of the invention.

FIG. 8A gives an example of an Individual Response Page where therespective contributions of each Invitee are known at the end of the PEPProposal Establishment Phase. This will occur where the contributionsare to be made in equal shares and where the numbers of Participants isset at a particular number (rather than as a range) at step 406. It willalso occur where the Participants will be contributing amounts specifiedby the Coordinator as at step 404. As illustrated in FIG. 8A, thesecombinations can be described in the same manner.

FIG. 8B gives an example of an Individual Response Page where theParticipants are to contribute in equal shares, but where the finalnumber of Participants is not known by the end of the process. Thiswould occur where the Coordinator specifies a minimum, maximum, orminimum and maximum number of Participants rather than a set number atstep 406. In this case, it is possible to calculate a range of amountsto be paid by each of the Participants, but the final amount cannot beknown until the total number of Participants has been determined.

FIG. 8C gives an example of an Individual Response Page where theInvitees choose the amount of their contribution at step 405.

FIGS. 8A, 8B and 8C provide examples of how Individual Response Pagescan be tailored to explain the Purchase Terms in a simple and directmanner in each of the main variations of the present embodiment of theinvention. They contain a number of common elements:

-   (i) A note of welcome and a brief invitation to contribute towards a    joint purchase item or items for a specific person along with an    explanation of the reason for the purchase (i.e. details of    occasion): 801, 810, 819;-   (ii) Details about the various Invitees, and the current status of    their invitations (along with, where appropriate, the amounts of the    requested or actual contributions): 802-805, 811-813, 820-824. FIGS.    8A, 8B and 8C show three alternative indicators of the current    status of the invitations: “agreed”, “declined” and “awaiting    response”. Those familiar with the art would know that it would be    possible for the server system to display other indicators,    including: “received but not yet opened”, or “received and opened”;-   (iii) A statement explaining the consequences of participation to    the Invitee: 806, 815, 825. This sets out the steps that will be    followed if the Invitee agrees to participate where both the    Purchase Terms have been satisfied and where they have not been    satisfied;-   (iv) An option for the Invitee to agree to or decline the    invitation: 807 and 808, 816 and 817, 826 and 827;-   (v) An opportunity for the Invitee to obtain a more comprehensive    explanation of the system and method: 809, 818, 828.

Those familiar with the art will know that some of the above elementscan be omitted or rearranged or adapted in various ways. It would alsobe possible to include additional information if required. For example,the page might include a summary tablet showing the number of Invitees,the number who have agreed to or declined their invitations, andstatistics such as the average contributions made by each Participant.The information might be conveyed using text or graphics or acombination of text or graphics.

The layout shown in FIG. 8A is the simplest of the three exampleIndividual Response pages. It displays an invitation for the Invitee tocontribute a specific, nominated amount ($Z.00) 801 and also shows thespecific amounts requested from the other Invitees ($X.00 and $Y.00)804.

In contrast the Individual Response Page represented by FIG. 8B does notshow the specific amounts requested from any of the Invitees. Asdiscussed above, this cannot be known until the final number ofParticipants has been determined. Therefore, FIG. 8B shows the range ofamounts that the Invitee might be liable to pay, which is calculated onthe basis that a minimum or maximum number of Invitees agree toparticipate 814. FIG. 8B also contains an optional statement that mightbe used to give dynamic information regarding the range ofcontributions, which is up-dated as the number of committed Participantschanges 814.

FIG. 8C covers the situation where the Invitees choose the amounts oftheir contributions (possibly within specified ranges) 820. Under thisscenario, the process culminates as soon as the required amount has beenraised between each of the Participants. Important pieces of informationthat might be shown under this scenario are the target amount, theamount raised to date and the remaining outstanding balance 821.

c) The choice to accept

Invitees can signify their intention to participate in the PEP Proposalby clicking on the relevant section of the Individual Response Page(807, 816, 826). In one embodiment of the invention, performing thisaction would take the Invitee to a payment acceptance page (FIG. 9),where he or she would then be asked to enter the details required forthe transfer of funds with the relevant electronic payment system. Forexample, Participants using credit or charge cards may be asked to entertheir names (901, 902 and 903) and select the type of credit or chargecard from a list provided in a drop-down menu (904 and 905). They maythen be asked to enter the relevant card number (906 and 907) and cardexpiry date (908, 909 and 910).

The payment acceptance page also contains a section that indicates theamount or range of amounts of the contribution to be made by theParticipant (911, 912 and 913). In order to avoid confusion andunworkable proposals, the payment acceptance page must be configured sothat it only accepts payments for amounts that are consistent with thePurchase Terms. Accordingly, the precise operation of this section wouldvary depending upon the nature of the Purchase Terms established by theCoordinator. For example, there are certain circumstances where theexact amount of each contribution would be known as soon as theCoordinator sets the Purchase Terms. These are discussed in relation toFIG. 8A above. Here, the payment acceptance page would display the,precise amount of the required contribution as an un-editable field (sothat it cannot be changed or altered by the Invitee) 912. Where theInvitee would be agreeing to a range of amounts (as discussed inrelation to FIG. 8B above) both the minimum amount and the maximumamount of the contributions would be displayed (912 and 913). Thisinformation could be dynamic in the sense that it displays the range ofcontributions calculated not simply by reference to the Purchase Terms,but also by reference to the actual number of Invitees who haveindicated they will participate (for example, the required minimumnumber of Invitees might be three, but four may have already agreed toparticipate, which would decrease the maximum amount payable by eachParticipant). Where the Invitees choose the amount of their owncontribution (as discussed in relation to FIG. 8C above), the paymentacceptance page must ensure that certain nominated amounts are rejected.For example, some amounts may be below or above a range nominated by theCoordinator. Further, Invitees should not be able to nominate amountsthat exceed the outstanding balance. Preferably, the entries made by theInvitees should be verified on the client systems using a client-sidescripting language, as well as by the Vendor's server system.Client-side scripting expedites the process of identifying any logicalerrors because the relevant entries can be checked without the need toupload to the server system. A short explanation reminding the Inviteeof such restrictions may also appear on this web page 914.

The Invitee is then given an option to continue or to go back 915 and916. Going back will take the Invitee to the Individual Response Pageand give him or her the opportunity to decline the invitation. If he orshe clicks “continue” after entering the required information, theParticipant will be taken to a status page (described at section (d)below). The Invitee may optionally be taken to one of the generale-commerce pages 105 on the vendor's web site 102.

d) Status Pages

After the Invitees have entered their credit card details, the serversystem may send each of them a web page which displays the currentstatus of their particular PEP Proposal (Status Page). Each Participantcan return to the Status Page at regular intervals to check on theprogress of their particular PEP Proposal (possibly after entering apassword). It is desirable for the Status Pages to present informationto the Participants in a manner that is tailored as far as possible tothe relevant Purchase Term combinations selected by the Coordinator.

Some of the information that may be included on the Status Pageincludes:

-   -   a description of the nominated purchase item(s);    -   a brief summary of the Purchase Terms;    -   the identity of the other Invitees;    -   the status of the various invitations made under the relevant        PEP Proposal;    -   the number of Invitees who have agreed to participate;    -   the current maximum and minimum contribution amounts (where the        Participants are to contribute in equal shares); and    -   the amount raised to date, and the amount to be raised before        any target is reached.

The Status Pages merely utilise conventional aspects of e-commerce andthey are not described in detail here.

5. Watchdog algorithms

The timely and accurate assessment of the progress of each PEP Proposalis crucial to the effective operation of the present invention. EachParticipant has an interest in identifying when the PEP Proposal hasfailed or cannot be satisfied at the earliest possible time. This giveseach Participant as much time as possible to arrange an alternativejoint purchase. The vendor also has an interest in identifyingunsuccessful PEP Proposals at the earliest possible opportunity becausethis will assist its inventory management. Further, purchasers generallyhave an interest in their individual contribution amounts being smallerrather than larger. Where the purchase is to be made in equal shares,and the Coordinator has specified that a minimum and maximum number ofParticipants is acceptable, the individual contributions will decreaseas the number of Participants increases. In such circumstances, it isdesirable for a PEP Proposal to be kept open if there is a chance thatmore Participants will join in to lower the individual contributionamounts. This is referred to as “optimisation”of the PEP Proposal.

In the preferred embodiment of the present invention, the server systemassesses each PEP Proposal in light of these considerations usingvarious watchdog algorithms. The assessment is made automatically,without the involvement of the vendor or Participants. The server systemassesses each PEP Proposal at periodical intervals marked by “evaluationmilestones”. The two evaluation milestones that trigger the operation ofthe various watchdog algorithms described below are the receipt ofresponses from new Invitees, and the change of date. This algorithm canbe implemented in any number of languages (including Visual Basic, C,C++, Pascal and Java), and is executed by an operating system specificscheduling service (such as Server Agent on Windows 95, Windows 98, TaskScheduler on Windows 2000 or cron on Unix etc). The various ways toimplement the following algorithms using these various software systemswill be obvious to one skilled in the art.

(a) Purchase in equal shares

FIG. 10A illustrates the process by which the server system can evaluatea PEP Proposal where the Participants contribute in equal shares 1006.It shows that such a PEP Proposal will be judged to be successful wherethe current number of Participants (Part_(c)) is greater than or equalto the required minimum number of Participants (Part_(min)) (i.e.1007=yes), and:

-   -   the maximum number of Participants (Part_(max)) has also been        reached (i.e. Part_(c)=Part_(max)) (1010=yes); or    -   while the maximum number of Participants has not been reached        (i.e. Part_(c)≠Part_(max)) (1010=no), all the Invitees have        responded (1011=yes) and additional people cannot be invited        (1012=no); or    -   while the maximum number of Participants has not been reached        (i.e. Part_(c)≠Part_(max)) (1010=no), all the Invitees have        responded (1011=yes) and additional people can be invited        (1012=yes), but the current date (Time_(c)) equals the cut-off        date (Time_(T)) (in other words, the cut-off date has been        reached) (Time_(C)≧Time_(T)) (1009=yes); or    -   the maximum number of Participants has not be reached (i.e.        Part_(c)≠Part_(max)) (1010=no), and while all of the Invitees        have not responded (1011=no) the cut-off date has been reached        (Time_(C)≧Time_(T)) (1009=yes).

FIG. 10A also illustrates that a PEP Proposal will be judged to beunsuccessful where the minimum number of Participants has not beenreached (Part_(C)≠0 Part_(min)) (1007=no), and:

-   -   the cut-off date has been reached (Time_(C)≧Time_(T))        (1001=yes); or    -   the cut-off date has not been reached (Time_(c)<Time_(T))        (1001=no), all Invitees have responded (I_(T)=I_(RESP))        (1002=yes), and additional people cannot be invited (1004=no);        or    -   the cut-off date has not been reached (Time_(C)<Time_(T))        (1001=no), the total number of Invitees (I_(T)) is greater than        the number of Invitees who have responded (I_(RESP)) (i.e. not        all Invitees have responded) (I_(T)>I_(RESP)) (1002=no), the        number of Invitees yet to respond (I_(T)−I_(RESP)) is less than        the number of Participants that must still agree to join in for        the PEP Proposal to be successful (Part_(MIN)−Part_(c))        (1003=no) and additional people cannot be invited (1004=no).

FIG. 10A illustrates that a PEP Proposal needs to be re-evaluated where:

-   -   the minimum number of Participants has been reached        (Part_(c)≧Part_(min)) (1007=yes), and while the maximum number        of Participants has not been reached (Part_(c)≠Part_(min))        (1010=no), and all the Invitees have responded (1011=yes),        additional people can be invited (1012=yes), and the cut-off        date has not been reached (Time_(C)<Time_(T)) (1009=no); or    -   the minimum number of Participants has been reached        (Part_(c)≧Part_(min)) (1007=yes), the maximum number of        Participants has not be reached (Part_(c)<Part_(min)) (1010=no)        and while all of the Invitees have not responded (1011=no), the        cut-off date has not been reached (Time_(C)<Time_(T)) (1009=no);        or    -   the minimum number of Participants has not been reached        (Part_(c)<Part_(min)) (1007=no), the cut-off date has not been        reached (Time_(C)<Time_(T)) (1001=no), not all Invitees have        responded (I_(T)>I_(RESP)) (1002=no), and the number of Invitees        yet to respond is greater than or equal to the number of        Participants that must still agree to join in for the PEP        Proposal to be successful (I_(T)−I_(RESP)>Part_(MIN)−Part_(C))        (1003=yes); or    -   the minimum number of Participants has not been reached        (Part_(c)<Part_(min)) (1007=no), the cut-off date has not been        reached (Time_(C)<Time_(T)) (1001=no), not all Invitees have        responded (I_(T)>I_(RESP)) (1002=no), the number of Invitees yet        to respond is less than the number of Participants that must        still agree to join in for the PEP Proposal to be successful        (I_(T)−I_(RESP)<Part_(min)−Part_(C)) (1003=no), but additional        people can be invited to join in (1004=yes).

In all cases, where the server system judges that a re-evaluation isrequired, there is a delay until the next evaluation milestone isreached.

(b) Purchase in amounts specified by the Coordinator

FIG. 10B illustrates the process by which the server system can evaluatea PEP Proposal where the purchase is made in amounts specified by theCoordinator 1015.

It shows that such a PEP Proposal will be judged to be successful wherethe current amount raised (AR_(c)) equals Total Price (P_(T)) (i.e., thetotal price has been raised) (1016=yes).

It also illustrates that such a PEP Proposal will be unsuccessful where:

-   -   the total price has not been raised (AR_(C)≠F P_(T)) (1016=no)        and the cut-off date has been reached (Time_(C) 2 Time_(T))        (1017=yes); or    -   the total price has not been raised (AR_(C)≠P_(T)) (1016=no) and        while the cut-off date has not been reached (Time_(C)<Time_(T))        (1017=no), at least one Invitee has declined his or her        invitation (1021=yes) and Invitees cannot be substituted        (1020=no).

FIG. 10B illustrates that such PEP Proposals need to be re-evaluatedwhere:

-   -   the total price has not been raised (AR_(C)≠P_(T)) (1016=no),        the cut-off date has not been reached (Time_(C)<Time_(T))        (1017=no), and no Invitees have declined their invitations        (1021=no); or    -   the total price has not been raised (AR_(c)≠P_(T)) (1 016=no),        the cut-off date has not been reached (Time_(C)<Time_(T))        (1017=no), and while at least one Invitee has declined his or        her invitation (1021=yes), Invitees can be substituted        (1020=yes).        (c) Purchase in amounts chosen by the Participants

FIG. 10C illustrates the process by which the server system can evaluatea PEP Proposal involving the purchase where Participants contributeamounts of their choice 1023.

Such a PEP Proposal will be judged to be successful where the TotalPrice has been raised (AR_(C)=P_(T)) (1024=yes).

It also illustrates that such a PEP Proposal will be unsuccessful where:

-   -   the Total Price has not been raised (AR_(C)≠P_(T)) (1024=no) and        the cut-off date has been reached (Time_(C)≧Time_(T))        (1025=yes); or    -   the Total Price has not been raised (AR_(C)≠P_(T)) (1024=no),        the cut-off date has not been reached (Time_(C)<Time_(T))        (1025=no), the total number of Invitees have responded        (I_(T)=I_(RESP)) (1031=yes) and additional people cannot be        invited (1030=no); or    -   the Total Price has not been raised (AR_(C)≠P_(T)) (1024=no),        the cut-off date has not been reached (Time_(C)<Time_(T))        (1025=no), the total number of Invitees have not responded        (I_(T)>I_(RESP)) (1031=no), but there is a maximum contribution        (C_(max)>0) (1027=yes) and the maximum contribution multiplied        by the number of Invitees who have yet responded        (I_(T)−I_(RESP)) is less than the total price minus the current        amount raised (P_(T)−AR_(C)) (1028=no), and additional people        cannot be invited (1030=no).

FIG. 10C illustrates that such a PEP Proposal must be re-evaluatedwhere:

-   -   the Total Price has not been raised (AR_(C)≠P_(T)) (1024=no),        the cut-off date has not been reached (Time_(C)<Time_(T))        (1025=no), the total number of Invitees have responded        (I_(T)=I_(RESP)) (1031=yes) and additional people can be invited        (1030=yes); or    -   the Total Price has not been raised (AR_(C)≠P_(T)) (1024=no),        the cut-off date has not been reached (Time_(C)<Time_(T))        (1025=no), the total number of Invitees have not responded        (I_(T)≠I_(RESP)) (1031=no) and there is no maximum contribution        (1027=no); or    -   the Total Price has not been raised (AR_(c)g F P_(T)) (1024=no),        the cut-off date has not been reached (Time_(C)<Time_(T))        (1025=no), the total number of Invitees have not responded        (I_(T)≠I_(RESP)) (1031=no) there is a maximum contribution        (C_(max)>0) (1027=yes), and the maximum contribution multiplied        by the number of Invitees who have yet responded        (C_(max)×(I_(T)−I_(RESP))) is greater than the total price minus        the current amount raised (P_(T)−AR_(C)) (1028=yes); or    -   the Total Price has not been raised (AR_(C)≠P_(T)) (1024=no),        the cut-off date has not been reached (Time_(C)<Time_(T))        (1025=no), the total number of Invitees have not responded        (I_(T)≠I_(RESP)) (1031=no), there is a maximum contribution        (C_(max)>0) (1027=yes) and the maximum contribution multiplied        by the number of Invitees who have yet responded        (C_(max)≠(I_(T)−I_(RESP))) is less than the total price minus        the current amount raised (P_(T)−AR_(C)) (1028=no) and        additional people can be invited (1030=yes).        6. Payment Administration

As discussed, the present invention involves a delay between the timewhen an Invitee agrees to become a Participant, and the time when thePEP Proposal is successful. Accordingly it is important for the systemand method to administer payment processing securely and effectively.

The standard way for coordinating payments in e-commerce transactions isto charge credit cards in real time as soon as the relevant details havebeen received. This means that value would be transferred from theParticipants to the vendor at or about the time that the card detailsare provided. A number of problems are associated with using this methodin conjunction with the present invention. If the Purchase Terms are notmet, it would be necessary to credit each Participant's account for therelevant amount (a process known as “charging back”). This may involvedelay, and may involve bank charges. Moreover, Participants might beunwilling to have their credit cards charged before the Purchase Termshave been met. Further, under some of the possible Purchase Termscombinations that may be established using the present system andmethod, the precise amount payable by each Participant is not knownuntil all of the Invitees have responded to their invitations or thecut-off date has been reached. It would not be possible to ensure thesecredit cards are charged the correct final amount before this time.

The preferred method for addressing these payments is utilises directdebit pre-authorised payments. This would involve the Invitee's Bank 114and the Coordinator's Bank 111 or Invitee's Bank 114 storing a record ofa pre-authorised debit amount by placing a “hold” over a certain portionof the Invitee's credit limit. Often the interaction between thesevarious banks (111, 113 and 114) and parties (101, 104 and 108) iscoordinated by a Gateway system 112. Where the Participants consent to arange of payments being charged to their credit cards, the hold could beplaced over the maximum amount that might be charged to their card. Ifthe Purchase Terms are met, the vendor would initiate a payment requestin its capacity as a direct debit originator. Use of this method has awould mean that the Invitee's credit card is only charged where thePurchase Terms have been met, and that it would not be necessary for thevendor to store commercially sensitive information on its system whilewaiting for the Invitees' responses. It also avoids the possibility ofhaving the payment refused due to changes in the customer's creditstatus between the response and the debit request.

An alternative method for handling this problem would be for theParticipants to make the payments to a third party who would hold themin escrow, pending the successful completion of the PEP Proposal. Thisis potentially a more convenient option than a credit card charge back,as organisations that specialise in managing escrow payments can effectthe return of funds more quickly than do banks. Nevertheless it mayinvolve additional charges and some delay.

A third, less sophisticated way of approaching the problem would be forthe vendor to use standard pre-authorised payments. This involves using“real time” payment authorisation but to delay the request for thatauthorisation until after the Purchase Terms have been met. In oneembodiment of the invention, this method would require the vendor tostore the relevant credit card details on its own system in a paymentdatabase 110. The financial details of each Participant are entered intothis database over a secure network through the PEP-related pages 109 onthe vendor's web site 102, however this information should notaccessible via the web site in the same way as access to informationcontained in the PEP Proposal database 107 or Inventory database 103.Further, while stored in the payment database 110, the data should beencrypted so that it would be of no use to unauthorised persons whoobtain it. In the event that the Purchase Terms are met, the vendorwould ask its Acquiring Bank 113 for authorisation to accept the paymenttendered by the customer, and would transmit the credit card data alongwith this request. Using this alternative, the vendor's system wouldneed to ensure that the expiry date of the credit card or charge card isafter the cut-off date. This is because if the credit card expiry dateoccurs after the cut-off date the Participant's bank would refuse thedebit request at the time it is made by the vendor.

In a variation of this embodiment, it would be possible for the vendorto outsource the storage and handling of the data to the Gateway System112. An identifier would be assigned to the financial data stored by theGateway System and this identifier would either be the same as that usedby the vendor for the relevant PEP Proposal, or cross-referenced to thatidentifier. When the Purchase Terms for a particular PEP Proposal aresatisfied, the Server System would send a message to the Gateway Systemidentifying the PEP Proposal and requesting it to coordinate therelevant payments.

The use of this method of delayed requests for “real time” paymentauthorisations has a number of advantages over the simple “real time”authorisation method. If the vendor delays before initiating the requestfor payment until the Purchase Terms are satisfied, this would mean thatthe precise amount payable by each Participant will be known in allpossible combinations of the Purchase Terms. Further, utilising thismethod would ensure that the Participant's credit cards are not chargedin the event that the Purchase Terms are not met.

However there are two main disadvantages associated with this method.The need to store credit card and other details requires the vendor'ssystem or the gateway system to take measures to ensure the security ofdata over a period of time. These can be very costly, and there is arisk that such measures can be breached. A second disadvantage is thepossibility of refusals being made by the banks when the vendorinitiates the request for payment. This possibility would exist even ifthe vendor obtains an initial authorisation to accept the Participant'scredit card details at the response date. This might be because theParticipant's credit limit could have been exceeded between the date ofthe response and the date of the request for payment, or the credit cardmay be lost or stolen. Therefore, pre-authorised direct debits are to bepreferred.

7. Order administration

Where the vendor sells a physical product rather than a service, theserver system would also administer a database of stock or inventory106. This database would typically contain a list of the productsoffered by the vendor for sale and a record of the quantity of each ofthese products held in stock. Where the items are not in stock theInventory Database might also contain an estimate of the time it willtake to bring the item into stock.

It would be possible for the server system to mark the chosen item asreserved in the inventory database 106 pending the successful completionof the Purchase Terms. This is important to the vendor's inventorymanagement, as the vendor must have at least one of each item in stockready to be delivered when required. Alternatively, a selected itemmight not be in stock when first selected by the Coordinator, and itwould be necessary to ensure the item is in stock should the PurchaseTerms be satisfied. However vendors also have an interest in minimisingthe level of stock on hand in order to reduce costs. Given thepossibility that PEP Proposals may not result in the purchase ofnominated items, it may be uneconomical to reserve or order into stockevery item nominated for purchase using the present invention.

The vendor can manage inventory levels using estimates based onaccumulated experience with the present system and method. Historicaldata can be compiled by using information obtained from the PEP ProposalDatabase 109. This data may include information such as the percentageof PEP Proposals that proceed successfully to completion, or moresophisticated data such as the proportion of successful PEP Proposalsthat result once a certain percentage of the money is raised or acertain percentage of Invitees agree to participate. This data could besubjected to statistical analysis which accounts for seasonal variationsat various points in time throughout the year (e.g. Christmas). All suchinformation can be used to manage the levels of stock in the PEPprocess.

1. A retailing method executable by a computer system, said methodcomprising: sending a page from said computer system to a prospectivepurchaser in response to a request, said page being associated with aspecific product; said computer system receiving a purchase proposalfrom said prospective purchaser for direct joint purchase of saidproduct at a fixed price, the purchase proposal including identifierinformation of plural other persons nominated by the prospectivepurchaser and purchase term information selected at least in part by theprospective purchaser, said nominated plural other persons beingnominated to contribute to said direct purchase of said product at saidfixed price such that the direct joint purchase of said product can onlybe made by one or more of said nominated persons, and said purchaseproposal being formulated in part by the prospective purchasernominating a contribution scheme selected from a plurality ofcontribution schemes provided by said computer system, each scheme beinga different way to divide the exact purchase price among theparticipants; sending terms of the purchase proposal using said computersystem to the nominated persons, the terms sent to each nominated personincluding the identity and/or contribution of each of the othernominated persons and a request for payment; said computer systemreceiving, in response to said request for payment, respective paymentinformation from two or more of the nominated persons; said computersystem processing said payment information using the mechanism of directdebit pre-authorized payments to secure a hold in respect of at leastone contribution; said computer system initiating payment requests toenable the direct joint purchase to be completed in accordance with thesaid purchase term information; and said computer system ensuring thatthe sum of all received payments equals said fixed price.
 2. The methodof claim 1, wherein said prospective purchaser is one of said nominatedpersons.
 3. The method of claim 1, further comprising: receivingidentifier information of one or more further persons also nominated tocontribute to said direct joint purchase of said product at said fixedprice; wherein the direct joint purchase of said product can only bemade by said prospective purchaser and/or one or more nominated personsconsisting of the previously nominated persons and the one or morefurther persons.
 4. The method of claim 1, wherein each request forpayment sent to said nominated persons specifies a corresponding paymentamount so that the sum of the payment amounts equals said fixed price.5. The method of claim 1, wherein each request for payment specifies arange of amounts for a corresponding range of numbers of contributors tosaid purchase so that each sum of payment amounts for a correspondingnumber of contributors equals said fixed price.
 6. The method of claim1, further comprising: receiving contribution information relating tosaid selected contribution scheme from said prospective purchaser;verifying the consistency of said contribution information with saidselected contribution scheme; and provided there is such consistency,transmitting proposal information to said nominated persons accordingt., the identifier information, said proposal information including alink to said purchase proposal.
 7. A retailing method executable by acomputer system, said method comprising: sending a page from saidcomputer system to a prospective purchaser in response to a request,said page being associated with a specific product; said computer systemreceiving a purchase proposal from said prospective purchaser for directjoint purchase of said product at a fixed price, with the terms of thepurchase proposal; a) including identifier information of plural otherpersons nominated by the prospective purchaser; b) purchase terminformation selected at least in part by the prospective purchaser, saidnominated plural other persons being nominated to contribute to saiddirect purchase of said product at said fixed price such that the directjoint purchase of said product can only be made by one or more of saidnominated persons; and c) being formulated in part by the prospectivepurchaser selecting one contribution scheme from a plurality ofcontribution schemes provided by said computer system, such contributionschemes including at least two of the following: i) a scheme whichassists the prospective purchaser to establish said purchase terms byinviting nominated persons to contribute in equal amounts that togetheradd up exactly to said fixed price; ii) a scheme which assists theprospective purchaser to establish said purchase terms by invitingnominated persons to contribute in unequal amounts selected by theprospective purchaser that together equal said fixed price; or iii) ascheme which assists the prospective purchaser to establish saidpurchase terms by inviting nominated persons to contribute in amountsselected by the nominated persons that together equal said fixed price;sending terms of the purchase proposal using said computer system to thenominated persons, the terms sent to each nominated person including theidentity and/or contribution of each of the other nominated persons anda request for payment; said computer system receiving, in response tosaid request for payment, respective payment information from two ormore of the nominated persons; said computer system processing saidpayment information using the mechanism of direct debit pre-authorizedpayments to secure a hold in respect of at least one contribution; saidcomputer system initiating payment requests to enable the direct jointpurchase to be completed in accordance with the said purchase terminformation; and said computer system ensuring that the sum of allreceived payments equals said fixed price.
 8. The method of claim 7,wherein said prospective purchaser is one of said nominated persons. 9.The method of claim 7, further comprising: receiving identifierinformation of one or more further persons also nominated to contributeto said direct joint purchase of said product at said fixed price;wherein the direct joint purchase of said product can only be made bysaid prospective purchaser and/or one or more nominated personsconsisting of the previously nominated persons and the one or morefurther persons.
 10. The method of claim 7, wherein each request forpayment sent to said nominated persons specifies a corresponding paymentamount so that the sum of the payment amounts equals said fixed price.11. The method of claim 10, wherein each request for payment specifies arange of amounts for a corresponding range of numbers of contributors tosaid purchase so that each sum of payment amount is for a correspondingnumber of contributors equals said fixed price.
 12. A retailing methodexecutable by a computer system, said method comprising: sending a pagefrom said computer system to a prospective purchaser in response to arequest, said page being associated with a specific product; saidcomputer system receiving a purchase proposal from said prospectivepurchaser for direct joint purchase of said product at a fixed price,with the terms of the purchase proposal: a) including identifierinformation of plural other persons nominated by the prospectivepurchaser; b) purchase term information selected at least in part by theprospective purchaser, said nominated plural other persons beingnominated to contribute to said direct purchase of said product at saidfixed price such that the direct joint purchase of said product can onlybe made by one or more of said nominated persons; and c) beingformulated in part by the prospective purchaser nominates the purchaseterms by selecting one contribution scheme from a plurality ofcontribution schemes provided by said computer system, such contributionschemes including at least two of the following: i) a scheme whichassists the prospective purchaser to establish said purchase terms byinviting nominated persons to contribute in equal amounts that togetheradd up exactly to said fixed price; ii) a scheme which assists theprospective purchaser to establish said purchase terms by invitingnominated persons to contribute in unequal amounts selected by theprospective purchaser that together equal said fixed price; or iii) ascheme which assists the prospective purchaser to establish saidpurchase terms by inviting nominated persons to contribute in amountsselected by the nominated persons that together equal said fixed price;receiving contribution information relating to said selectedcontribution scheme from said prospective purchaser; said computersystem verifying the consistency of said contribution information withsaid selected contribution scheme, and provided there is suchconsistency, transmitting proposal information to said nominated personsaccording to the identifier information, said proposal informationincluding a link to said purchase proposal; sending terms of thepurchase proposal using said computer system to the nominated persons,the terms sent to each nominated person including the identity and/orcontribution of each of the other nominated persons and a request forpayment; said computer system receiving, in response to said request forpayment, respective payment information from two or more of thenominated persons; said computer system processing said paymentinformation using the mechanism of direct debit pre-authorized paymentsto secure a hold in respect of at least one contribution; said computersystem initiating payment requests to enable the direct joint purchaseto be completed in accordance with the said purchase term information;and said computer system ensuring that the sum of all received paymentsequals said fixed price.